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Teaching the Computer to Add: An Example of Probi em-Solving in an 

Anthropomorphic Computer Culture 

by Cynthia J. Solomon 

The project of defining numbers and setting up the rules of 
addition has been undertaken or discussed in elementary school math 
classes, in college mathematical logic classes, in computer science logic 
design, in systems programming courses and in child psychology courses, and 
so on. In each case very different aspects of the project have been 
stressed. Here, we look at the project as an example of problem solving in 
what we have called an Anthropomorphic Computer Culture. 

This paper describes how to teach a computer to add numbers. 
"Teach?" t you might say, "does that mean program?" Yes f the paper 
describes a programming project and how a student might develop it. So 1 1 
gives a model for developing programs. But there is something else. 
Learning to add numbers is an experience we have all had. fly model of 
developing the program uses ourselves as an anthropomorphic model for the 
computer (a useful resource for student programmers) and the computer as a 
model for us (a useful resource for everyone). The paper is really about 
. ways to think about doing thse two things at once. Hence its unorthodox 
style. Much of it is in the form of a mono log which tries to reflect what 
goes on in my mind as 1 work on such a project; at least that part of what 
goes on which I would offer to a beginner as a model. 

In elementary school kids are presented with "number facts" and 
"addition facts". But they are deprived of a most valuable and important 
notion: what it is like to make up a set of rules, to define a domain 
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under which these rules can be consistently applied. Kids are not given a 
chance to see the process at work, get a feel for the power of recursion, 
or get a sense of how procedures are built up, debugged, elaborated. The 
kids are not helped to look for tricks (or look at some "facts' 1 or 
techniques as tricks towards making problems easier to deal with.) The 
Idea that you can develop your own set of heuristics is a very important 
contribution to your own problem-solving abilities. Maybe an even more 
Important idea is that of learning from mistakes or "bugs" and developing 
debugging techniques, but in a world where everything is a "fact" it is 
hard to appreciate or get involved with debugging processes. 

This reaction might also be encountered in recursive function 
theory classes where the idea of recursion is known, but its real power as 
a problem solving instrument is not felt and where the Peano axioms are 
received as "facts" (albeit formal proofs are introduced.) Students come 
out of the experience as if they had undergone a s%t of well proscribed 
exercises. They think of recursion and inductive methods as hocus pocus, 
not something that is real ly practical , but something to be applied in very 
special situations like courses in recursive function theory or induction! 
They do not see the deep imp I i cat ions which this rich project offers them. 

Of course, the case might be made for the overwhelming 
difficulty in giving kids a taste for debugging, heuristics, process, 
procedure without the use of computers. But in many computer courses, this 
project is again viewed very narrowly as an exercise, not as a way of 
gaining insights into the nature of intelligence. 

Ue present a different point of view; here, in this computer 
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culture, we explore this project a9 a legitimate research question. Ue 
will build our own system, find our own way. Ue might draw upon personal 
knowledge of number facts and skill algorithms. 
A View of the Computer Culture 

Computers open up new ways to learn about the development of 
knowledge and thinking. The computerist — the computer scientist-teacher- 
mathematician-psychologist — can create a culture in which it is possible to 
observe students engaged in a learning process. Ue can experiment with 
teaching techniques and content areas. And thus, we can develop a computer 
culture conducive to learning for a range of students from naive to expert. 
So we take a bare computer and enrich it with languages to talk in and 
, attach devices like turtles and music boxes so we have concrete things to 
do and talk wi th. 

One reason turtles were introduced into this culture was to 
concretize an underlying heuristic principle in problem-solving — 
anthroppmorphize! Hake the idea come alive, be someone — albeit it lives 
only in the mind. Talking .to inanimate objects and thus giving them life 
1^ an implicit pattern in our lives; we have tried to turn it to advantage 
and make it an explicit process. The turtle world is one example and 
easily fosters the idea of developing mental imagery for concretizing 
abstractions. But throughout this culture anthropomorphisms abound; we see 
the computer, the program, the debugging process, etc. as people we can 
talk to and talk about. Ue extend this even further to imagine "little 
men* 1 residing in the computer and coming alive to carry out a procedure, 
then disappearing. 
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LOGO, the programming language we use, is designed to encourage 
anthropomorphisms. LOGO is procedural and recursive* The importance of 
having a procedural language is born out by our hypothesis that an 
essential aspect of the growth of our knowledge base is the process of 
absorbing local procedures into a hierarchical structure where only the 
top-most procedure is even recalled by name or description. 

He observe the development of our programs from one buggy state to 
another, Ue feel ourselves learning from these bugs as we carefully modify 
the procedures so that their behavior grows closer to our goal state. As 
our experience- increases we see that some bugs afford us brilliant new 
insights into unexpected ways of achieving results. Ue begin to watch for 
them, ready to capitalize on bugs. Bugs are living creatures which we 
name, pamper, scold, laugh at, laugh with, and learn from and enjoy. 

Another anthropomorphic influence on the programming language 
design affected procedure names and variable names. Their composition has 
few restrictions and their size can be longer than most people want to 
type. In this anthropomorphic computer culture naming is an important 
element. It helps to separate out and identify one procedure from another 
and one bug from another. Again, the explicit use of naming as a problem- 
solving tool is recognized as an essential ingredient. A first step toward 
creative development for beginners occurs when they make up their first 
procedures and in so doing must give them names. This parallel activity 
can really be mind-blowing. The student "teaches a new word" to the 
computer. This power, to define and create, to give meanings to words, is 
reemphasized by the project described below. The same feeling of power 
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offered to beginners in their first experiences defining procedures is 
reinforced even more strongly when as more sophisticated students they 
create procedures to add numbers. 

Discussing the Project 

In the next sections a style of problem solving is presented in 
the context of developing an actual program for addition. The style is 
discursive and reflective as I attempt to fol low through the project as if 
I were doing it now while talking to you* 

The way the procedures are constructed in this paper reflects a 
definite style of problem-solving. Rather than making a formal plan first 
by flow charting for example, I rely on a procedural approach which is more 
natural and intuitive. Procedural thinking and in particular recursive 
thinking in themselves encourage a structuring and planning out. Advice 
like: Reduce the problem, simplify, do first what you know how to do, 
defer problems, try to limit the number of jobs any one procedure has to do 
eo that 1 1 a role is clear — is an active part of the procedural development 
of a program. 

Here is an example of the kind of discussion which might occur 
wi the students. 

First of all let's remember we want to make up an addition 
operation so that we can say 

PRINT ADD 1G 532 
and the computer will say 

548. 
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Ue also have to remember that there are no arithmetic operators (helpers) 
aval I able to us. 

How do computers really add? Some people answer: it's in their 
hardware; it's built into the system; it's hardwired. Is addition 
"hardwired" into our system, are we like computers and so i f a wire is 
loose we can' t do it. 

It is true that arithmetic is a very necessary part of any 
computer's hardware, but the hardware is made up of "logical units" which 
are based on the same ideas we will investigate. "UeM, could we do 
without arithmetic primitives?" To the beginner it real ly doesn' t seem 
possible. It's like recursion you tell me addition is not primitive but 
emotionally it just seems unthinkable. Uhat about addition in children. 
Is It really a primitive or are there pieces of knowledge which are 
acquired. Maybe we are so familiar with addition that we forget its 
components. Yes, addition is a familiar operation. But what if we had to 
tell a little man how to add? Uhere do we start? Ue might ask ourselves 
if we know of a similar experience. Hey, look what we have to do is "teach 
the computer" to add ~ just like we might teach a person! Ue I I now 
teachers teach kids to add, we were once those kids, how did we learn - can 
we give ourselves some tips (But I thought it was hardwired and teacher 
just. . ) . 

At this point in past discussions two suggestions emerge. 
Teachers say we have to teach the computer the "number facts" and 
computerists say we have to build a 10 x 16 table. Great, I say, a 
beginning. To the teachers I ask hou do we teach the number facts and what 
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are they and how many of them are there. To computer students I ask is a 
IB k 10 table large enough and how do we organize it. The teachers will 
face these issues too, after all making a table is a way of "teaching" 
number facts. 

Uhat kind of table and what are number facts. A table of the sums 
of the first 108 numbers is very limited and building a larger table is 
still very limited. Is that what I have in my head. Isn't there a key 
Idea or two that I could bui Id on without exhausting the computer* s memory. 

Is it the case that children learn "number facts" like IB + 20 - 
36 as a primitive notion or is there a more primitive idea underlying it 
all. Uhat do kids learn about numbers. They learn about their 
relationship to each other. They learn to order them. Sesame Street 
teaches kids to count from 1 to 18 (and now to 28). Let's pick up on that 
and teach the compputer to count. 

Counting by 1 

A first description of a procedure for counting might look like 

the following command: 

TO COUNTUP : NUMBER 
10 PRINT ADD1 sNUtlBER 
END 

What we have is a procedure requireing one input, a number. COUNTUP* s job 

is to print the number fol lowing this input. To do this, we know, 1 must 

be added to :NUf1BER. Of course, we don f t yet know how to do that job. But 

we apply a powerful heuristic — we pretent we know so that we can describe 

how to count. That is we imagine we have all the procedures we need to do 



/~*N 



PAGE 8 



the job. What ue are doing nou is getting a feel for what those needs are, 
then naming and listing them, and then putting their details aside until 
later. 

Actually ue can temporarily "cheat" and define ADD1 to be 
SUM 1 :NUMBER 

;.. I.e. , 

TO ADD1 tNUflBER 

18 OUTPUT SUM 1 :NUnBER 

END 

Ue will replace this "phoney" algorithm later!! 

Pnmfnp 1 ^' In L ° G ? ^ ere are 2 P rocedur « typasi commands and operations. 
InmT 1 S 3 C °T nd ' * d069 80,nethin g but doesn't send back a message 
ADO! is an operation; it does send back a message. 

Now ue uant to really understand uhat COUNTUP does. One method ue 
offer la to trace through the script of a procedure in the guise of little 
men. Set into paper-and-penci I action a concrete example of COUNTUP at 
work. Thus 

COUNTUP 25 



: NUMBER is 25 
18 PRINT 26 





lone. 



We embellish LOGO with a kind of meta-language in uriting out uhat is 
happening. He use arrows to indicate flou. 

Was this hou you expected COUNTUP to behave? Not really. COUNTUP 
was supposed to continue counting. It. uas supposed to 

COUNTUP ADD! iNUMBER 
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and then COUNTUP ADD1 ADD1 : NUMBER 
and then COUNTUP ADD1 ADD1 ADD1 t NUMBER 
and so on. 

He can look at the problem a little differently. 

The action is to take :NUMBER and 

PRINT AUDI : NUMBER 

then we want that same action to be performed 

on ADD1 : NUMBER and so on. 

We'll, let's tell COUNTUP to do just that. Ue change COUNTUP. 

TO COUNTUP : NUMBER 
10 PRINT ADD1 : NUMBER 
28 COUNTUP ADD1 : NUMBER 

■:.. END 

COUNTUP tells itself to COUNTUP. Good. Let's trace through this version. 
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EFFECT 



COUNTUP 26 
■$> 



t NUMBER is 2G 
18 PRINT 27 - 
28 COUNTUP 27 

Yaleem 







i NUMBER is 27 
18 PRINT 28 - 
20 COUNTUP 28 

' ^ 

{sleep ' 



:NUf1BER is 28 
16 PRINT 29' -J 
20 




Okay, COUNTUP seems to be working well. It is a simple recursive procedure 
which doesn't know how to stop by itself. Ue see the little men never 
report back, they never disappear, but remain in a dormant state. Let's 
change the script by extending it to include a description of when the job 
Is done and the process should be stopped. 

To complete the description we have to give COUNTUP more 
Information, another input. This second input could be an upper bound 
which :NUHBER must never exceed or it could be the number of times the 
process should be repeated starting from : NUMBER. The first way seems 
limiting and confusing in possible situations like 

COUNTUP 19 17 
Hhere there would be no visible effect of COUNTUP doing anything. So we 
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follow the alternate suggestion. 

Although we could change COUNTUP, let's not. Instead we wl I I make 
a new procedure, REPEATADDl, and give it 2 inputs. 

TO REPEATADDl t NUMBER : TIMES 
Its visible action is the same as COUNTUP's 

PRINT ADD1 : NUMBER 
except REPEATADDl is going to stop on its own. 

In deciding how to describe the STOP rule, we look at various 
possibilities. Ue could use a cute programming trick based on the "number 
fact" that if we reduce sTIMES by 1 each time the PRINT action is taken , 
: TIMES ui I I eventual ly become 8. So we could 

test itihes'- e 

and 

IFTRUE STOP 
Oh, but we don't know how to reduce by 1. He don't know yet how to 
increase by IN So let's keep this possibility in mind for later on when 
»e have plowed though the whole job. For now. let's look for another 
method, which will use only addition. 

?i«n^ I0N! V* the infi>< form of EQUAL U9ed here as a truth-valued 

V PeP f P n0t aS a nUmeric "W"". By the way this special form 
more !°?f \\ ver \^ M T« pedagogic point of view because it ?. a 
more eKphc.t^tatemen^o^what is happening and easier to debug than 

Well, of course, we could conjure up a new specialist which couunts up from 
8 (instead of down to 0) until it reaches : TIMES. Let's call the 
specialist "COUNTER. It can be a third input to REPEATADDl. 
TO REPEATADDl : NUMBER : TIMES : COUNTER 
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Then 

18 TEST » TIMES'- : COUNTER 
28 IFTRUE STOP 
otheruise 

38 PRINT A0D1 :number 

and noH turn the job over to the next little man, but give him the changed 
Inputs. 

48 REPEATAD01 

ADD1 :NUMBER 

:TIMES 

ADD1 iCOUNTER 

EN0 

DIGRESSION: A procedure with 3 inputs!! It's strikingly cumbersome. True 
enough and ue will alleviate the situation by creating a super procedure. 
But It is extremely important to see that there are 3 separate roles to the 
job. By naming them we can talk about them. 

Now let's see our little men at work. 
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REPEATADD1 23 2 8 

—-> o 

j NUMBER is 23 
: TIMES is 2 
: COUNTER is 8 
18 TEST 2-8 

28 IFTRUE 

38 PRINT 24 




REPEATADD1 24 



t NUMBER 

: TIMES is 2 

: COUNTER is 1 




IB TEST 2 - 1 (false) 
28 - — 



38 PRINT 25 

48 REPEATADD1 2S 2 2 

f sleep ) 



t 



.•NUMBER is 25 

: TIMES is 2 

: COUNTER is 2 ^ — . 

18 TEST 2 - 2 (true) 

28 IFTRUE STOP v — y 




(done) 
Viakeup") <r^~~^ 



?i nllJJll l h, \ W,n J 0f P |a W in 9 computer" really helps in debugging and 
in„ 9 h»! ""^rstand.ng the flow of a process. But it is person™, and 
you have to be the initiator to really appreciate the help 

Nog that REPEATADD1 Morks we can create a superprocedure to handle 
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tCOUNTER. let's make C0UNTBY1 serve that purpose. 

TO C0UNTBY1 : NUMBER > TIMES 
18 REPEATADD1 

rNUMBER 

tTIMES 

8 
END 
Now we try it. 

COUNTBY1 51 8 

■""""' 52 "■■ "" 

53 
54 
55 
56 
57 
58 
59 

Great!! 

Hey look, 51 + 8 - 59. Ue really have an adding machine!! 

There is a problem. The job isn't really done. Ue really are 
only interested in the final number not the intermediate ones. Ue might 
not always want to print the number. Ue want to be free to decide what to 
do with the result each time we set the procedure in motion. Stated in 
LOGO terms we want C0UNTBY1 to be an operation not a command. Ue want 
C0UNTBY1 to send back a message. 

TO C0UNTBY1 : NUMBER tTIMES 
18 OUTPUT REPEATADD1 

:NUMBER 

:TIMES 

8 
END ■"..-.■ 

But, of course, for this change to work REPEATADD1 must be transformed into 

an operation. Okay, let's do it. " 
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Let's look at REPEATADD1 as it now is. 



TO REPEATADD1 : NUMBER : TIMES : COUNTER 

19 TEST :TIMES - :COUNTER 

28 IFTRUE STOP 

38 PRINT ADD1 :NUMBER 

48 REPEATADD1 

ADOl :NUMBER 

jTIMES 

ADD1 tCOUNTER 
END 

Let's go through the script and see what needs changing so that we can 
convert REPEATADD1 to an operation. There are 3 actions taken by 
REPEATA001. 

1. when : TIMES-: COUNTER the procedure halts 

2. a number is printed 

3. the job is repeated on new inputs 

Let's decide what changes need to be made in each case. 

1. Instead of only halting when the job is done we want to send 
back : NUMBER. So 

IFTRUE OUTPUT :NUMBER 

2. Ue no longer want to print, so we can erase line 38. 

3. In this case where the job is repeated but with new inputs. It 
Is clear that the resultant action is what needs to be output. So 

48 OUTPUT REPEATADD1 

A0D1 :NUMBER 

: TIMES 
T . . ■ . u . ADD1 :C0UNTER 

This Is obv.ous but also hard for many people to accept after a moment's 

reflection. Oh, the magic of recursion!! Uel I, i t's not so magical. Put 
yourself into the place of little men. Play computer yourself. 

For example, imagine you want to increase 17 by 1. So you give 
the job to REPEATAD01. 
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REPEATA0D1 17 1 8 



t 




: NUMBER is 17 
: TIMES is 1 

: COUNTER is 8 A A 

18 TEST 1-8 (false) 

28 

3EPEATAOD1 18 1 1. 




48(0UTPU 
the message is 18 



\i 




£ 



£ 



: NUMBER is 18 
: TIMES is 1 
: COUNTER is 1 
18 TEST 1-1 
_2gJFTRUE ou 
the message i 




f there was no Instruction telling what to do with the message a BUG Mould 
have occurre d causing the computer to exclaim Hihat do I do uith 18'. 

-^ ■ - i — i^SSSSSC— — ■— ii I " ii "■ i ■ 



It looks like ue have an operation which will do the job. Of 
course, the whole process depends upon ADD1. It's now time to look closely 
at what is needed there. 
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ADOlng 1 to a Number 
Let's add 1. 
18 + 1 — > 19 
276 + 1 > 277 

When we add 1 to a number we really transform the last digit of 
the number. So what we want is to take the number apart. 

1 and 8 
Then change 8 to 9. 
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Then put the new number together. 
1 and 9 

This should be easy. Let's call this Input "NUMBER, so 

I40RD 

BUTLAST : NUMBER 
DIGITADD1 LAST : NUMBER 

Thus 
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TO ADD1 :NUMBER 

10 OUTPUT I40RD 

BUTLAST tNUMBER 

DIGITADD1 LAST .-NUMBER 
ENO 

Notice Me have changed the problem to one which involves only digits~10 
elements. 

Adding 1 to a digit is simple. If the digit le 6. then the result 

Is 7. If the digit is 8. then the result is 1. So we merely follow 

through on this idea and we have a procedure. 

TO DIGITADD1 :DIGIT 

10 TEST :DIGIT - 

20 IFTRUE OUTPUT 1 

30 IF .-DIGIT - S OUTPUT 6 

50 IF sDIGIT-9 OUTPUT 10 



SI?w S !n N: ^ * 0ti ^ W8 haVe t0 Check for each digit and so it doesn't 
:bout r tne Zl ;; d condftS.° n /^ inPUt ' 9 identity - Not ^ru latter 

A0D1 20— > 21 
AD01 346 > 347 

It looks like this procedure is working!! 

Let's try countbyl. 

C0UNTBY1 8 7 — > IS 

COUNTBYl 18 7 — > 115 
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huh . . . uhat* 9 this! 

C0UNTBY1 17B 5 > 1711 

Oh, no! He have a bug!! Look 

C0UNTBY1 176 5 
should really be 181 not 1711. Oh, ha, look- It's a CARRY bug 



1 



m 



i ■■.-.■...........,. 

should be 7+1, I.e., 8. 
Okay, let's look closely at what ADD1 does when the last digit of Its input 
Is 9. 

ADD1 9 — > 18 
That's okay. 

AD01 19 — > 118 
Ugh!! 

But now we know the bug, we can find a cure. He have to take 
special action when the last digit is 9. So 

TO AD01 :NUnBER 

10 TEST 9 « LAST : NUMBER 

28 IFTRUE 
Uhat should be done? That's simple. 

ADO 1 to BUTLAST : NUMBER 

and join that to 8 In place of LAST :NUMBER 
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28 IFTRUE OUTPUT UORD 

ADD1 BUTLAST : NUMBER 
8 



38 OUTPUT UORD 

BUTLAST i NUMBER 
DIGITADDl LAST : NUMBER 

END 



The ultimate test might be 
ADD1 999 > 1888 



SUPERADD 

There is still a slight problem. Imagine we want to add 99 and 
9999. Ue will need 1888 little men, all alive although in a dormant state. 
That's tooo much both time-wise and work-area-size-wise. To be practical 
we have to reduce the amount of work. Ue can do that by applying the same 
methods we used in ADD1. Change the problem to be addition of digits whose 
results get concatenated together. So 

TO ADD :N1 :N2 

The pi count by one from LAST :N1; do it LAST :N2 times; do the same for 

the rest of the digits in :N1 and :N2; stick it all together. 

UORD 

ADD BUTLAST :N1 
BUTLAST :N2 
C0UNTBY1 LAST :N1 
LAST :N2 

Repeat this until either :N1 or :N2 is stripped of everything. 
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38 TEST EflPTYP :N2 
48 IFTRUE OUTPUT :N1 
58 OUTPUT UORD 

ADD BUTLAST :N1 
BUTLAST :N2 
COUNTBY1 LAST s Nl 
LAST iN2 
END 



Extensions 

The project is done in a sense, but it is not closed to 
extensions. For example, you could reurlte the procedures using SUBTRACT1 
as uell as ADD1. Better still, you could extend the domain to include 
negative numbers or even decimals. Another direction to take is to make up 
other arithmetic operations like MULTIPLY or DIVIDE or extend this to any 
base system or build a modular arithmetic system, etc. 

Are there some number operations which must be built into the 
programming language at a more primitive level? The one that comes 
Immediately to mind is CLOCK, an operation Mhich reports on the ticks of 
the computers clock. Uhat about operations not restricted to numbers? 
Uhich are really primitive? 



